In distributed database systems, changes in a primary database need to be replicated to one or more target databases in order to maintain data integrity across the entire system. A common way to accomplish the replication is to record the changes made to the primary database in a transaction log and then replicate the recorded changes to the target databases using replication systems. Once the recorded changes have been safely replicated from the transaction log to the replication systems, they can be deleted, or truncated, from the transaction log to free up space in the transaction log for recording additional changes in the primary database.
A problem can arise in this arrangement, however, when the transaction log data is replicated to multiple replication systems via multiple parallel paths. For instance, assume that transaction log data needs to be replicated to both a first replication system and a second replication system using first and second paths. Invariably, there will be differences in the times it takes to transmit the data via the different paths and differences in times it takes for the replication systems to process the data. What these (and other) differences between the two paths means is that it is possible for the transaction log data to have been successfully replicated to the first replication system but not yet to the second replication system and vice versa. Thus, it may be safe to truncate the transaction log with respect to one of the replicating systems, but not the other. As such, it can be difficult to determine when the transaction log data can be properly truncated from the transaction log.
In the drawings, like reference numbers generally indicate identical or similar elements. Additionally, generally, the left-most digit(s) of a reference number identifies the drawing in which the reference number first appears.